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EXECUTIVE  SUMMARY 


This  report  Is  essentially  a guide  to  the  preparation  of  an  integrated 
master  program  schedule  for  the  development  of  a weapon  system.  It  can 
be  applied,  however,  to  any  complex  acquisition  effort.  The  report 
discusses  major  problems  associated  with  the  development  of  a master 
schedule  and  deals  with  the  need  for  such  a schedule.  The  use  of  a 
master  schedule  is  also  discussed  along  with  some  pros  and  cons  associated 
with  computerized  scheduling.  The  report  stresses  the  need  for  programs 
to  keep  their  scheduling  techniques  simple  until  SPO  personnel  have 
learned  how  to  use  the  schedule  and  have  documented  the  need  for  more 
complex  procedures.  Lastly,  the  report  recommends  methods  of,  and 
sources  for,  data  collection  as  the  schedule  is  being  constructed. 
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SECTION  I 


INTRODUCTION 


The  student  of  systems  acquisition  management  within  the 
Department  of  Defense  (DOD)  quickly  learns  that  there  are  three  basic 
parameters  which  are  used  to  control  the  acquisition  process;  system 
cost,  system  performance,  and  the  acquisition  and  deployment  schedule. 
Traces  of  this  conceptual  viewpoint  can  be  found  throughout  the  official 
directives  within  the  DOD  that  set  forth  policy  and  guidance  for  the 
conduct  of  the  system:  acquisition  process.  (For  example,  see  DOD 
Directive  5000o28) 

In  recent  years,  let's  say  5 to  7,  there  has  been  an  increasing 

drive  within  the  DOD  to  give  the  cost  parameter  equal  weight  with  schedule 

and  performance  as  a driving  factor  in  the  acquisition  process.  ‘ ''ucb  has 

been  written  about  this  trend  and  I do  not  intend  to  give  a detailed 

account  of  these  developments  in  this  paper.  Rather,  I would  like  to 

quote  what  former  Deputy  Secretary  of  Defense  Clements  said  in  1973  when  he 

(1) 

made  design  to  cost  goals  mandatory  for  all  DSARC  level  programs. 

"These  Implementation  plans  should  provide  the  services  and  their  program 
managers  authority  to  make  the  performance  and  schedule  adjustments 
necessary  to  achieve  design  to  cost  levels."  (emphasis  mine) 


(1)  Memorandum  for  Secretaries  of  the  Military  Departments, 

Defense  Systems  Acquisition  Review  Council  Principals,  June  13,  1973 
Design  to  Cost  Ob.lectlvcs  on  DSARC  Programs. 
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In  structuring  this  introduction  as  I have,  I am  hoping  that  the 
reader  will  forgive  my  unwillingness  to  pursue  the  rise  of  cost  as  an 
equal  or  even  predominant  factor  in  the  acquisition  process  and  concentrate 
instead  on  the  implications  of  such  a policy  on  the  other  two  parameters. 

During  the  past  18  months  I have  been  assigned  to  the  Systems  and 
r.esources  Management  Action  Group  in  the  Air  Force  Chief  of  Staff's  Office 
and  the  Program  Management  Assistance  Group  at  the  Headquarters  Air  Force 
Systems  Command  (AFSC) . This  period  of  time  has  given  me  a chance  to  make 
numerous  visits  to  the  three  Buying  Divisions  of  AFSC,  most  of  the  Air 
Force  Plant  Representative  Offices  (AFPROs),  and  many  of  the  labs  and  other 
centers  within  the  Air  Force  where  major  weapon  systems  are  procured.  This 
first  hand  experience  (as  a consultant  not  an  inspector)  has  lead  me  to 
the  conclusion  that  many  Air  Force  program  offices  lack  the  ability  to 
develop  and  manage  the  detailed  scheduling  required  to  bring  a major  program 
through  the  DSARC  process  while  making  meaningful  cost  to  schedule  trade- 
offs,. 


The  purpose  ot  this  paper  Is  to  describe  to  the  reader  the  kinds  of 
scheduling  problems  I have  encountered  (sanitized  in  regards  to  program 
specifics)  while  examining  the  Business  Strategy  of  many  Air  Force  programs 
and  to  document  ray  view  on  how  to  develop  an  in-house  scheduling  capability 
within  the  program  office. 
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SECTION  II 


WHY  AN  INTEGRATED  MASTER  SCHEDULE? 

SOME  HORROR  STORIES 

Evury  Program  in  DOD  has  a "schedule".  The  review  process  of  the 
services  assures  that  some  form  of  schedule  is  developed.  Many  programs, 
however,  have  two  loosely  connected  levels  of  scheduling.  The  most 
detailed  level  is  usually  a PERT  or  CPM  type  chart  which  is  prepared  by 
the  contractors  Involved  in  the  program.  The  less  detailed  level  is 
usually  prepared  by  the  SPO  and  used  for  the  program  review  process.  This 
level  often  contains  only  the  amount  of  detail  that  can  be  presented  on  a 
slide  or  viewgraph. 

Many  of  the  problems  that  will  be  cited  in  this  chapter  have  as  their 
genesis  the  fact  that  the  programs  did  not  have  an  integrated  program 
schedule  and  Instead  utilized  the  two-level  approach  described  above. 

I have  spent  considerable  time  over  the  past  several  years  attempting 
to  explain  to  people  who  are  at  levels  of  the  acquisition  community  other 
than  the  System  Program  Office  (SPO),  or  even  people  within  SPOs  who  are 
away  from  the  scheduling  process,  what  is  happening  today  in  the  schedule 
area  of  the  three  parameters.  Cost,  Schedule  and  Performance.  My 
experience  has  taught  me  that  most  people  are  skeptical  when  you  describe 
problems  in  the  acquisition  process  unless  you  can  cite  concrete  examples 
to  prove  your  point.  This  chapter  contains  a collection  of  such  examples, 
"sanitized",  of  course,  but  "real-world"  none  the  less. 
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The  Integrated  Master  Schedule 

In  order  to  understand  why  certain  programs  get  into  scliedule 
trouble  or  build  unworkable  schedules  one  needs  a frame  of  reference 
regarding  what  a program  schedule  should  consist  of.  I have  developed 
the  following  definition  to  explain  what  I mean  by  an  integrated  master 
schedule : 

"An  Integrated  master  schedule  is  a detailed  program  schedule  which 
portrays  all  of  the  major  elements  of  a program  and  all  related  development 
efforts  in  such  a manner  that  the  interrelationships  are  easily  seen.  The 
schedule  is  updated  regularly  and  is  recognized  by  all  program  personnel  as 
the  master  schedule  and  the  only  schedule  authorized  for  publication  outside 
the  program.  The  schedule  is  reviared  and  validated  at  least  monthly  by 
the  program  manager." 

Some  Horror  Stories 

Over  the  past  two  years  I have  been  a consultant  on  seven  Air  Force 
programs  that  meet  the  DOD  5000.1  criteria  for  DSARC  review  and  not  one 
had  a program  schedule  which  could  be  described  as  even  close  to  the  above 
definition.  All  of  the  programs  had  the  overview  schedules  utilized  for 
program  reviews  at  higher  levels  of  authority.  Most  had  detailed  schedules 
available  which  had  been  submitted  by  the  contractors  for  various  parts 
of  the  program  in  question.  None  of  the  programs  had  a control  room  and 
none  updated  schedules  on  a regular  basis.  None  had  a policy  in  effect 
for  controlling  the  scheduling  process  or  for  release  of  schedule  Information. 
The  following  are  real  world  examples  of  what  resulted: 
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(a)  One  program  had  au  acquisition  strategy  which  was  close  to 
the  classical  contract  definition  method.  Two  contractors  were  being 
carried  through  the  validation  and  demonstration  phase  with  the  idea  of 
selecting  one  contractor  for  Full  Scale  Engineering  Development  (FSED). 

Both  contractors  were  required  to  submit  proposals  for  FSED  based  on 
proposal  Instructions  which  were  to  be  furnished  by  the  program  offlceo 
These  instructions  were  to  be  based  on  the  resulf  of  the  trade-offs 
conducted  by  the  contractors  during  the  validation  phase.  Unfortunately, 
the  program  office  had  no  schedule  for  this  process  or  for  approaching  the 
DSARC  II  gateo  Because  of  this,  the  program  office  drifted  into  a situa- 
tion where  they  had  only  two  weeks  to  analyze  the  final  reports  of  both 
contractors  and  integrate  these  results  into  a single  system  specification 
and  statement  of  work  and  forward  these  to  the  contractors  for  the  develop- 
ment of  FSED  proposals.  Needless  to  say,  the  mad  rush  that  resulted 
produced  a less  than  optimum  request  for  proposal  package. 

(b)  One  program  was  developing  several  different  kinds  of  communica- 
tion equipment.  Some  of  this  equipment  was  to  be  installed  as  GFP  as  part 
of  the  communication  equipment  of  another  much  larger  program.  At  the  same 
time,  significant  amounts  of  this  equipment  was  promised  as  GFP  to  a new 
development  effort  within  the  SPO  then  in  source  selection.  Because  no 
one  in  the  SPO  except  the  engineer  in  charge  of  the  technical  aspects  of 
the  equipment  in  question  knew  the  status  of  the  development  schedule 

the  SPO  found  Itself  grossly  over  committed.  The  Program  Director  on  the 
major  program  was  an  influential,  dynamic,  and  firm.  General  Officer. 

As  a result,  all  available  units  went  to  his  program.  Because  of  this  a 
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very  sensitive  source  selection  had  to  be  modified  and  extended.  The 
final  result  was  that  the  source  selection  dragged  on  for  over  one  year. 

(c)  One  program,  a major  high-visibility  program,  had  the  mission 
of  producing  a piece  of  equipment  and  an  enormous  amount  of  facilities  to 
furnish  to  another  government  agency  as  a part  of  a national  program.  Both 
the  equipment  in  question  and  the  facilities  would  be  required  to  interface 
with  many  DOD  and  non-DOD  systems  hence  the  need  for  much  intra-program 
integration  effort.  The  Advanced  Procurement  Plan  (APP)  of  the  program 
indicated  that  a number  of  medium  sized  integration  contracts  were  con- 
templatedo  These  contracts  were  to  be  controlled  and  managed  by  the  program 
office  in  a sort  of  "integrating  the  integrators"  effort.  Unfortunately, 
the  positions  for  the  personnel  within  the  SPO  needed  to  implement  this 
strategy  were  not  approved.  Because  of  this  the  SPO  rather  leisurely 
decided  to  switch  strategies  and  procure  integration  through  one  single, 
large,  omnibus,  integration  contract.  The  average  procurement  lead  time 
for  such  a contract  at  the  buying  division  in  question  was  (54)  weeks 
for  a competitive  award.  As  of  3 weeks  before  the  needed  award  date  the 
SPO  had  not  notified  their  procurement  staff  of  the  change  in  strategy  or 
drafted  the  SOW  or  SPEC  for  the  proposed  contracts.  This  SPO  had  several 
officers  devoted  full  time  to  scheduling,  but  these  officers  had  not 
developed  a master  schedule  and  instead  were  trying  to  develop  a computerized 
scheduling  process. 

(d)  Another  Instance  of  loss  of  control  occurred  on  a program  that 
had  as  part  of  its  mission  the  development  of  equipment  which  was  to  be 
utilized  in  several  smaller  programs  as  GFE.  The  program  developing  the 
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hardware  had  not  developed  a control  room  or  a procedure  for  control  of 
its  scheduling  process.  Because  of  this,  schedules  were  developed  and 
Issut  outsiders  by  project  engineers  without  approval  by  the  program 

manag'-f  The  result  was  that  different  program  schedules  were  furnished 

to  a iiuiafc  r of  different  organizations  outside  the  SPO.  Some  of  these 
outside  c ganizations  had  made  major  program  constructive  decisions  based 
on  these  diedules  and  had  to  restructure  a second  time  when  the  SPO 
finally  r /eloped  an  Integrated  schedule. 

I nmary,  I believe  that  within  the  Air  Force  systems  acquisi- 
tion cormunlty  many  programs  have  lost  their  ability  to  manage  the  schedule 
parameter  of  systems  acquisition.  Many  of  our  schedules, 

(a)  are  simplistic  (limited  by  the  size  of  a vlewgraph) 

(b)  do  not  Include  all  program  events 

(c)  are  not  updated  and  reviewed  on  a regular  basis 

(d)  are  not  controlled  in  a disciplined  manner 

(e)  are  not  Integrated  between  related  programs 

The  next  section  will  discuss  some  common  problems  encountered  in  the 


development  of  an  integrated  schedule 


SECTION  III 
SOME  COMMON  PROBLEMS 


This  section  is  presented  with  the  objective  of  acquainting  the 
reader  who  has  the  intent  of  developing  an  integrated  master  schedule 
with  problems  that  are  very  likely  to  arise  in  that  endeavor. 

Paying  the  Price  (It  Takes  Time  & People) 

There  are  no  free  rides  in  the  world  of  program  management  (or  the 
rest  of  the  world  for  that  matter).  Developing  and  maintaining  a master 
program  schedule  takes  time  and  effort.  That  has  to  be  understood  from 
the  very  beglnnlng„  The  key  to  making  this  investment  of  resources  cost 
effective  is  that  the  schedule  function  must  be  removed  from  the  various 
other  offices  in  the  SPO  and  placed  in  a central  office  such  as  program 
control.  Once  given  this  responsibility  this  central  office  must  resist 
the  tendency  to  rush  out  and  attempt  to  automate  schedules,  hire  consultant 
develop  fancy  facilities,  and  otherwise  inject  complex  procedures  into  the 
effort.  The  amount  of  resources  devoted  to  the  schedule  function  can  be 
kept  to  a miniraxim  while  still  producing  outstanding  work  if  emphasis  is 
placed  on  keeping  things  simple  and  of  high  quality  until  the  capability 
to  master  more  complex  methods  is  developed  within  the  SPO. 

Getting  Data 

The  ease  with  which  data  will  be  available  will  be  a function  of  where 
you  are  in  the  program  and  how  much  support  you  receive  from  the  "front 
office".  Most  people,  experienced  in  systems  acquisition,  tend  to  know, 
almost  instinctively,  that  Information  is  power.  They  are  therefore. 


reluctant  to  release  it  without  good  cause.  What  you  need  to  know  is 
where  to  get  data  from,  how  much  to  get,  and  how  often  to  get  it.  The 
answers  to  these  questions  will  be  presented  later  in  the  section  on  how 
to  develop  a master  schedule.  At  this  point,  however,  I simply  want  to 
make  the  point  that  getting  the  data  you  need  will  not  be  an  easy  task 
unless  you  are  prepared.  Prior  to  launching  out  on  this  task  I recommend 
that  you  develop  a list  of  the  information  you  need  and  obtain  the  front 
office's  "blessing"  prior  to  requesting  the  data.  Not  only  will  this  make 
your  task  of  getting  data  easier  but  will  probably  give  you  some  good  feed- 
back on  whether  or  not  you've  asked  for  the  correct  things.  Lastly,  you 
should  realize  that  data  from  outside  the  SPO,  from  contractors  or  from 
other  SPOs,  may  be  difficult  to  obtain.  Data  from  contractors  almost  alway 
involves  money  and  the  Contract  Data  Requirements  List  (CDRL) . Data  from 
other  SPOs  usually  involves  a Memorandum  of  Agreement  (MOA)  or  a personal 
contact.  More  will  be  said  on  this  later. 

Defense  Systems  Acquisition  Review  Council  (DSARC) 

The  scheduling  of  DSARC  decision  points  is  an  especially  difficult 
problem.  This  is  true  because  each  one  is  different  and  there  are  no  time 
limits  for  the  decision  process.  The  only  time  parameter  that  I know  of  is 
that  the  Decision  Coordinating  Paper  (DCP)  is  due  into  the  DSARC  principals 
for  coordination  30  work  days  prior  to  the  scheduled  DSARC  meeting,  and 
the  DCP  must  be  complete  for  Air  Staff  coordination  90  work  days  prior 
to  DSARC,  Maiy  programs  also  make  the  mistake  of  oversimplifying  the 
process  of  DCP  writing  and  coordination.  This  process,  together  with  the 
series  of  briefings  dealing  with  the  climb  up  the  military  chain  of  command 
on  the  way  to  the  DSARC  will  be  covered  in  detail  later. 
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Procurement  Leadtime 


The  underestimation  of  the  time  required  to  complete  complex  procure- 
ment actions  is  a common  problem  throughout  the  Air  Force  Systems  Acquisition 
community.  An  examination  of  the  reasons  for  the  extremely  long  lead  time 
requirements  for  complex,  large  dollar,  procurement  is  worthy  of  a study 
project  as  a separate  topic.  I do  not  intend  to  attempt  to  sort  the  reasons 
out  here.  What  is  important  to  the  planner  and  scheduler  is  to  make  a 
realistic  assessment  of  the  time  and  actions  required  to  complete  the 
procurement  cycle. 

There  is  a tendency  in  this  area  to  view  the  problem  as  one  belonging 
to  and  controlled  by  the  procurement  community.  This  view  is  simply  not 
viable  in  the  real  world.  There  are  a number  of  events  in  this  cycle  such 
as  preparation  of  the  Statement  of  Work,  CDRL,  Specifications,  and  other 
documents  that  simply  are  not  controlled  by  the  procurement  community.  It 

is  a fact  that  these  technical  documents  must  be  comnlete  before 
the  procurement  specialist  can  really  do  his  job.  Some  average  lead  times 
will  be  presented  later,  but  the  important  point  is,  what  is  the  lead  time 
in  the  procurement  organization  that  serves  the  progam  office  developing 
the  schedule? 

Symbology 

The  problem  that  many  programs  run  into  here  is  that  they  don't  adopt 
a common  symbology  for  use  throughout  the  program.  I remember  one  program 
that  had  no  integrated  schedule  beyond  the  viewgraphs  of  the  SPO 
director.  This  program  had  scheduling  done  by  each  division  and  by  each 
contractor  and  further  by  a systems  engineering  contractor  advising  the 
program  office.  All  of  these  groups  were  using  different 
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symbology.  Some  were  using  bar  charts,  others  milestone  charts,  still 
others  pert  type  event  charts.  When  all  of  the  hoge-poge  was  sorted  out 
the  program  had  some  major  problems  that  were  completely  masked  by  the 
disconnected  schedules  of  the  various  divisions  within  the  SPO.  How  to 
avoid  this  through  the  development  of  a master  integrated  schedule  is  the 
topic  of  the  next  section. 
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SECTION  IV 


HOW  TO  DEVELOP  A MASTER  INTEGRATED  SCHEDULE 


Discussions  of  past  probletns,  theoretical  concepts,  and  policy 
positions  do  little  to  help  the  person  In  the  program  office  who  Is 
charged  with  the  task  of  developing  an  Integrated  program  schedule^ 

This  section  has  the  objective  of  providing  that  help„  It  is  intended 
as  a practical,  step-by-step,  guide  and  covers  many  of  the  problems 
mentioned  in  the  previous  section. 

Getting  Started 

The  first  things  that  will  be  needed  (besides  time  and  people)  are 
materials  and  a good  place  to  work.  The  place  to  work  should  be  somewhere 
where  you  can  push  together  at  least  four  standard  size  DOD  conference 
tables.  It  should  also  be  available  on  an  uninterrupted  basis  for  at  least 
7 to  10  daysc  If  this  Is  not  possible,  the  only  solution  I know  is  to 
wrap  up  your  work  periodically  and  move  as  the  occasion  requires.  I’ve 
found  in  the  past  that  the  best  place  Is  usually  a conference  room  that  can, 
with  the  proper  support,  be  blocked  for  the  time  needed.  A good  supply  of 
the  largest  size  graph  paper  available  is  next„  I have  experimented  with 
both  36"  rolls  and  36"  x 36"  sheets.  Both  ultimately  have  to  be  taped 
together  but  the  rolls  tend  to  reduce  the  taping  requirements.  Next, 
procure  plenty  of  pencils,  erasers,  tape,  and  felt-tip  pens  of  a variety 
of  dark  colors  and  you  are  ready  to  start  the  layout. 
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The  Layout 


The  next  step  is  the  selection  of  a proper  system  of  grid  coordinates. 
These  should  be  selected  to  provide  you  with  the  length  of  time  you  need 
(on  the  schedule)  and  the  room  vertically  tc  list  all  the  interrelated 
parts  of  the  program.  Most  programs  require  a time  span  of  7 to  10  years 
to  portray  the  complete  program.  This  means  that  the  chart  should  be  at 
least  7 to  10  feet  in  length  so  that  each  month  can  be  represented  by  at 
least  one  inch  on  the  chart.  This  inch/month  is  strictly  an  approximation; 
the  exact  figure  should  be  selected  to  match  the  grid  length  on  the  paper 
being  used;  however,  on  extremely  detailed  charts  the  grid  should  be 
expanded  accordingly  up  to  the  space  available  to  hang  the  chart  (2"/month 
requires  14  feet  to  Indicate  7 years).  The  vertical  size  of  the  schedule 
should  be  at  least  4 to  6 feet  and  again,  expanded  or  contracted,  to  meet 
the  needs  of  the  program. 

After  selecting  the  scale,  the  grid  should  be  layed  out  on  the  tables, 
taped  together,  and  the  time  coordinates  plotted  on  the  chart  in  months, 
calendar  years,  and  fiscal  years.  This  time  scale  should  be  plotted  in 
a bright  color  to  aid  in  the  plotting  of  details  as  the  schedule  is 
constructed. 

Symbology 

There  are  a wide  variety  of  charting  techniques  and  types  of  symbology 
which  are  generally  acceptable  to  the  development  community.  I believe 
that  the  principal  purpose  of  these  techniques  and  symbols  is  to  communicate 
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and  therefore  strongly  lean  towards  the  selection  of  a set  of  symbols 
and  a charting  technique  which  is  most  familiar,  or  easiest  to  under- 
stand, for  the  personnel  within  the  program  in  question.  If  schedule 
data  is  already  being  received  from  a contractor  or  set  of  contractors 
it  would  be  best  to  utilize  the  same  symbology  used  on  these  schedules 
unless  this  symbology  is  extremely  hard  to  read  or  otherwise  difficult 
to  adopt  to  the  master  schedule.  It  is  important  to  realize  that  once  a 
standard  set  of  symbols  is  adopted,  data  which  is  not  provided  to  the  SPO 
in  this  format  will  have  to  be  translated  to  the  standard  S3nnbology  for 
plotting  on  the  master  schedule.  This  process  is  usually  quite  simple  and 
involves  little  more  than  converting  arrows  to  triangles,  or  blocks  to 
lines,  etc.  The  point  is  that  this  process  takes  time  and  can  be  minimized 
by  selection  of  the  proper  symbology  for  the  master  schedule. 

Some  good  references  which  illustrate  different  types  of  symboloby 
and  charting  techniques  are: 

(1)  AFSCP  800-3,  Chapter  6 

(2)  ASPR  1-2100,  Procurement  Planning 

(3)  Army  Pamphlet  No.  5-4-6,  Work  Scheduling  Handbook,  Jan  74 

(4)  AFSCP  800-23,  Secretary  of  Air  Force  SPR/PAR/CAR  Guidance 

(5)  AFSC  27-6  The  AFSC  Programming  Process 
Keeping  Track  of  Sources 

As  you  begin  to  build  your  master  schedule  you  will  be  gathering  data 
from  a wide  variety  of  sources.  I strongly  recommend  that  you  start  off 
right  with  a folder  for  each  data  source.  Each  folder  should  contain  a 
log  which  indicates  where  the  data  came  from,  who  your  contact  point  is, 
and  the  "as  of"  date  of  the  material  collected.  These  folders  will  not  only 


14 


help  you  find  things  in  a hurry,  but  will  give  you  a convenient  place  to 
store  your  material  when  it's  not  being  plotted  on  the  master  schedule. 
Lastly,  these  folders  provide  a chronological  history  of  how  your  data 
was  developed  as  time  passed. 

Program  Business  Strategy 

Before  you  begin  to  plot,  it  is  important  to  know  the  overall  business 
strategy  of  the  program.  There  is  a definite  relationship  between  this 
strategy  and  the  best  way  to  lay  the  schedule  out.  It  is  also  important 
to  know  where  the  program  is  in  regards  to  the  implementation  of  the 
strategy.  If  for  example,  the  program  is  in  the  conceptual  phase  of 
development  and  there  are  several  contractors  working  in  parallel  then 
it  would  be  wise  to  lay  the  schedule  out  so  that  the  detail  schedules 
of  these  contracts  are  close  enough  to  each  other  to  quickly  indicate  the 
relative  progress  being  made  by  each  contractor  with  respect  to  each  other 
as  well  as  with  respect  to  time  and  the  established  goals  of  the  conceptual 
phase.  On  the  other  hand,  if  the  program  is  mature  and  in  the  FSED  or 
production  phase,  there  is  likely  to  be  only  one  contractor  involved  in  the 
main  development  effort.  In  this  case  the  detailed  schedule  associated  with 
this  contract  should  be  plotted  adjacent  to  schedules  for  other  events  which 
could  impact  the  development  effort  such  as  GFE  deliveries,  test  schedules, 
or  related  program  schedules.  Remember,  however,  that  scheduling  is  an 
iterative  process.  If  during  your  first  attempt  the  layout  you  select 
turns  out  to  be  awkward  or  less  than  what  you  desire  — change  it.  Once 
the  data  has  been  gathered  and  plotted,  rearranging  it  in  better  groupings 
is  relatively  easy  to  do. 


Good  sources  of  data  for  this  kind  of  information  are  the  Program 
Management  Plan,  the  Program  Management  Directive,  and  the  Advanced 
Procurement  Plan.  If  the  strategy  is  not  contained  in  these  plans  (God 
forbid)  oi  they  are  not  yet  written,  the  place  to  start  is  the  Program 
Manager.  On  new  programs  that  are  just  getting  started  the  development  of 
a master  schedule  requires  the  overall  general  plan  of  the  program  manager 
and  a lot  of  crystal  ball  type  planning.  Difficult  though  it  may  be,  the 
construction  of  a master  schedule  at  this  time  is  possible  and,  in  fact, 
almost  essential  for  the  baseline  cost  estimates  required  for  the  program 
Initiation  decision  in  the  new  DODD  5000.1 
Existing  Contracts 

Now  that  a place  to  work  has  been  found,  materials  gathered,  time 
coordinates  established,  and  program  strategy  conceptualized,  hard  data 
can  be  plotted.  Since  all  weapon  systems  are  procured  through  contracts 
the  most  universal  place  to  start  plotting  is  the  existing  contract 
structure  within  the  program  office.  The  start  date  and  completion  date 
of  all  contracts  managed  by  the  program  office  should  now  be  plotted. 

These  plots  should  be  grouped  in  a logical  manner  as  discussed  above.  The 
data  needed  to  plot  these  start  and  end  dates  should  be  readily  available 
within  your  procurement  organization.  It  is  important  to  stress  here  that 
what  you  want  to  plot  is  the  actual  dates  in  the  contract  - not  some 
proposed  dates  to  be  added  later  - these  can  be  plotted  when  these  proposals 
are  negotiated  or  Incorporated  Into  the  contracts  by  change  order. 

The  major  milestones  between  the  start  and  complete  date  of  each 
contract  may  or  may  not  be  available  in  the  procurement  organization.  Most 
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contracts  require  the  contractors  to  work  according  to  some  schedule 
or  to  submit  to  the  government  their  proposed  work  schedules.  Larger 
development  contracts  usually  require  contractors  to  prepare  a master 
schedule  for  the  contract,  usually  a PERT  or  CPM  format  These  schedules 
are  usually  obtainable  from  the  technical  office  within  the  program  office 
that  monitors  the  work  in  question.  The  master  schedule  that  you  are 
developing  should  not  normally  duplicate  these  detailed  schedules. 

Therefore,  the  major  events  on  these  schedules  should  be  identified  so 
that  they  can  be  plotted  on  the  SPO  master  schedule.  Examples  of  these 
events  are  design  reviews,  equipment  deliveries,  report  due  dates,  program 
reviews,  configuration  audits,  etc. 

If  you  are  on  a new  program  and  do  not  know  what  kind  of  data  to  ask 
for  from  the  contractors  on  your  program  or  you  want  to  find  out  what  data 
the  contractors  are  required  to  submit,  you  should  visit  the  data  management 
officer  for  your  program.  The  data  management  officer  can  tell  you  what 
data  is  being  submitted  on  existing  contracts  and  should  be  able  to  tell  you 
who  it  is  being  submitted  to  from  his  copies  of  the  Contract  Data  Require- 
ments List  (CDRL),  The  data  management  officer  should  also  be  able  to 
show  you  descriptions  of  the  approved  schedule  data  items  which  can  be 
requested  from  contractors.  Lastly,  he  or  she  should  be  able  to  help  you 
tailor  these  data  items  so  they  will  generate  the  schedule  data  that  you 
and  your  program  need. 

Proposed  Contracts 

There  are  two  sets  of  data  that  you  need  here.  The  milestones  lead- 
ing to  contract  awards  and  the  proposed  milestones  on  the  future  contracts. 
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The  first  place  to  look  for  this  information  is  the  current  Advanced 
Procurement  Plan  (APP)  for  the  program.  Do  not  plot  this  data,  however. 
APPs  are  notoriously  out  of  date  almost  before  they  are  published.  The 
APP  can  serve  as  a guide  to  what  efforts  are  planned  in  the  next  year  or 
so.  The  latest  plan  for  getting  these  contracts  awarded  should  then  be 
obtained  from  both  the  procurement  and  technical  offices.  I say  both 
because  it  is  typical  that  these  two  sets  of  plans  will  not  agree.  What 
you  then  must  do  is  get  the  latest  information  from  the  technical  offices 
as  to  when  they  will  get  their  procurement  packages  over  to  the  procurement 
office,  then  obtain  from  the  procurement  office  what  the  procurement  mile- 
stones are  from  the  receipt  of  the  procurement  packages  to  contract  award. 

If  your  program  is  in  the  early  stages  of  development  you  may  have 
to  utilize  standard  times  for  procurement  lead  time  in  order  to  plot 
procurements  that  you  know  will  be  occurring  in  the  out  years  beyond  the 
scope  of  your  APP.  Appendix  1 indicates  average  procurement  lead  times  for 
a major  Product  Division  of  AFSC.  A similar  document  should  be  available 
from  the  procurement  staff  which  is  supporting  your  program.  If  no  such 
document  exists  I strongly  recommend  one  be  developed  since  procurement 
lead  time  will  be  a recurring  element  of  scheduling  and  planning  through- 
out the  life  of  any  program. 

The  other  set  of  data  that  you  need  on  future  contracts  is  the  proposed 
contract  milestones.  If  the  proposed  contracts  are  to  be  awarded  in  the 
near  future  this  data  may  be  readily  available  from  the  technical  office 
generating  the  requirement.  If,  however,  the  contract  is  one  that  lies 
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several  years  in  the  future,  perhaps  in  the  next  stage  of  development 
you  may  not  have  data  readily  available.  In  this  case  you  may  have  to 
ask  the  technical  office  in  question  to  produce  the  data  you  need.  It's 
very  likely,  however,  that  your  need  for  detailed  planning  in  these  out 
years  may  be  challenged.  If  this  occurs,  I recommend  that  you  take  a hard 
look  at  the  data  you  are  requesting  to  insure  you  are  asking  only  for  the 
data  you  need  to  construct  the  schedule.  To  do  this  you  may  have  to 
ask  yourself  what  are  we  doing  on  this  contract  and  what  does  it  contribute 
to  the  overall  program,  then  isolate  the  contributions  that  are  needed  to 
go  on  to  the  next  phase  or  to  conduct  other  actions  within  the  same  phase. 
The  dates  when  these  contributions  are  needed  then  become  your  major 
milestones  and  the  basis  for  further  construction  of  the  schedule.  If 
after  all  this  the  technical  offices  still  cannot  produce  the  dates  you 
need,  I recommend  that  you  develop  the  dates  yourself,  based  on  the  over- 
all time  constraints  of  the  program.  It  has  been  my  experience  that  people 
who  do  not  like  to  plan  suddenly  get  in  the  planning  business  when  others 
start  to  plan  out  year  program  events.  A good  source  of  data  for  "crystal 
ball"  planning  in  this  area  is  the  staff  level  people  at  your  buying 
organization.  Usually  these  people  have  seen  many  programs  come  and  go 
and  can  provide  sage  advice  on  hov;  to  "ballpark  schedule"  major  events 
such  as  PDR,  CDR,  Test  dates,  etc,  on  out  year  contract  efforts. 

Test  Schedules 

Test  schedules  are  of  critical  Importance  to  any  SPO  because  they 
usually  involve  the  combined  efforts  of  many  organizations.  Again, 


depending  on  where  your  program  is  in  the  development  cycle  these  scheduJes 
may  or  may  not  be  available.  A good  source  of  data  in  this  area  is  the  Test 
and  Evaluation  Master  Plan  (TEMP).  If  no  TEMP  is  available  or  it  is  out  of 
date,  revised  T&E  schedules  can  usually  be  obtained  from  the  T&E  section 
in  your  SPO.  There  are  several  things  that  need  to  be  considered  in 
developing  T&E  schedules,  some  of  the  most  Important  are  discussed  below. 
Hardware  Deliveries 

It  seems  incredible  to  me  that  people  need  to  be  told  to  keep  the 
hardware  schedule  and  the  test  schedule  in  sync,  but  experience  has  taught 
me  that  these  things  do  often  get  out  of  sequence.  The  test  schedule 
should  be  set  up  so  that  all  hardware  required  has  been  built,  inspected, 
checked  out,  and  modified  for  the  test  if  required.  All  this  must  be 
closely  monitored  to  insure  that  the  proper  tests  can  begin  on  time,  and 
remember,  the  test  range  gets  your  test  money  whether  you  come  and  test 
or  not,  so  if  you  are  late,  you  will  have  a bill  mounting  up  for  every 
day  you're  not  there  testing. 

Special  Test  Equipment 

Many  tests  require  special  test  equipment  or  special  equipment  for 
the  range  on  which  the  test  will  be  conducted.  This  equipment  has  to  be 
funded  with  SPO  money  but  is  often  procured  by  outside  agencies  such  as 
the  test  ranges.  Be  sure  to  find  out  whether  or  not  your  SPO  has  this 
kind  of  requirement  and  how  to  get  data  on  the  proposed  acquisition  effort. 
The  T&E  directorate  of  your  SPO  should  have  this  information.  If  not, 
find  out  where  the  testing  is  to  be  accomplished  and  try  the  range  Directors 
of  Operations.  Someone  there  should  be  a point  of  contact  for  your  program 
and  should  have  the  information  you  need. 
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Test  Results 

When  developing  your  schedule  be.  sure  to  leave  time  for  the 
reduction  and  analysis  of  test  data.  This  sometimes  takes  weeks  and 
even  months  and  can  come  at  a time  when  big  decisions  are  being  made. 

A SPO  that  does  not  leave  sufficient  time  in  its  schedule  for  this  effort 
is  really  saying  that  the  test  was  not  an  experience  in  ^'alidation  but  a 
waste  of  time. 

Test  & Evaluation  Funding 

The  National  Ranges  have  been  "direct"  or  "reimbursement"  funded 
since  1971,  This  means  that  the  cost  of  operation  of  the  ranges  is  paid 
for  partly  by  the  programs  that  use  the  ranges.  Once  you  have  agreed  with 
the  range  on  the  test  schedule,  and  the  scope  of  your  testing,  the  estimated 
cost  of  the  testing  is  negotiated.  After  this  happens  your  funds  are 
"fenced"  at  HQ  AFSC,  That  means  your  funds  go  to  the  range  whether  you 
do  your  test  or  not.  The  reason  for  this  is  the  fact  that  the  range  must 
commit  itself  to  your  test  prior  to  its  start  and  once  committed  cannot 
terminate  its  efforts  in  an  efficient  manner^  The  final  result  is  that 
testing  schedules  must  be  firmed  up  years  in  advance  in  order  to  get  the 
money  in  the  budget  and  once  planned,  cannot  slip  without  a great  amount 
of  lead  time  and  much  additional  cost. 

Program  Decision  Points 

Since  the  implementation  of  the  DSARC  process  through  the  5000  series 
of  DOD  instructions,  the  practice  of  structuring  DOD  programs  into  phases 
(Conceptual,  Validation,  FSED,  Production)  has  been  extended  down  to  even 
the  smaller  programs  within  DOD.  Small  programs  who  do  not  meet  the  DOD 


21 


criteria  for  DSARC  contained  in  DODD  5000.1  now  find  that  they  face 
similar  reviews  at  levels  of  the  DOD  below  OSD.  The  previous  section 
mentioned  some  of  the  problems  associated  with  these  reviews.  This 
section  contains  guidelines  for  overcoming  some  of  these  problems. 

The  DSARC  Review  Process 

The  scheduling  of  the  DSARC  process  begins  with  the  development  of 
the  information  required  to  develop  the  Decision  Coordinating  Paper  (DCP) 
and  the  DSARC  briefing,  and  ends  with  the  decision  of  the  Secretary  of 
Defense.  Some  of  the  events  in  this  process  are  controllable  by  the  SPO 
and  some  are  not.  All,  however,  can  be  planned,  and  some  kind  of  plan 
is  essential  to  the  control  of  the  overall  program  schedule. 

The  writing  or  update  of  the  DCP  is,  for  example,  an  event  controlled 
by  the  SPO.  The  coordination  of  the  DCP  is  a formal  process  within  the 
DOD.  In  the  Air  Force,  the  schedule  for  the  coordination  of  the  DCP  at 
the  Air  Staff  is  covered  by  HQ  USAF  01  800-1. 

In  addition  to  the  times  mentioned  in  800-1,  time  must  be  allowed 
for  review  at  HQ  AFSC  and  product  division  levels.  This  means  that  the 
information  needed  to  write  the  DCP  must  be  available  well  in  advance  of 
the  actual  DSARC  decision  point.  This  is  an  important  fact  in  the  layout 
of  the  overall  program  strategy. 

If  the  DCP  cannot  be  completed  until  certain  test  data  is  analyzed 
or  until  a certain  report  is  received  from  a contractor,  then  the  start 
of  the  DSARC  process  should  be  keyed  to  these  points.  A common  complaint 
against  the  DSARC  process  is  that  it  forces  programs  to  slow  down  or  pause 
and  creates  "gaps"  in  the  contractual  coverage  of  a program.  How  to 
minimize  these  prtiblems  will  be  discussed  later. 
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The  briefing  cycle  leading  to  a DSARC  meeting  is  an  example  of 
events  only  marginally  controlled  by  the  SPO.  The  best  advice  I can  give 
on  this  block  of  time  is  to  schedule  at  least  6 weeks  for  these  briefings 
and  be  prepared  to  travel  a lot.  Above  all,  be  organized  and  don't 
volunteer  briefings  to  people  or  agencies  that  cannot  help  your  program. 
Several  days  of  briefings  at  Product  Division,  HQ  AFSC,  and  Air  Staff  levels, 
hopefully  separated  by  10  days  to  2 weeks  is  a good  going  in  schedule  to 
propose. 

The  DSARC  decision  process  itself  is  almost  totally  outside  the 
influence  of  the  SPO.  Many  program  managers  seem  to  believe  that  if  they 
are  clever  enough,  or  if  they  tell  the  council  they  need  an  immediate 
decision,  they  can  get  a decision  in  one  or  two  days.  My  advice  is  to 
schedule  two  to  four  weeks  for  a formal  decision  and  be  sure  to  have  a 
contingency  plan  for  waiting  longer. 

Long  Lead  Approvals 

As  military  hardware  becomes  more  complex,  lead  times  tend  to  increase 
drastically.  In  most  weapon  systems  there  will  be  certain  items  with 
sufficiently  long  lead  time  to  require  firm  contractual  obligation  far 
in  advance  of  the  rest  of  the  weapon  system.  Complex  computers  are  an 
example  of  this  type  of  hardware.  Often  the  decision  to  order  these  items 
must  be  made  long  before  the  decision  to  move  the  weapon  system  into  full 
production  or  even  into  Full  Scale  Engineering  Development.  If  this 
situation  arises,  special  approvals  and  funding  allocations  will  be  required. 


These  long  lead  decision  points  should  be  clearly  indicated  on  the 
program  master  schedule  and  their  relationship  to  other  program  mile- 
stones closely  monitored.  One  program  I reviewed,  for  example,  was  not 
plotting  these  dates;  when  they  were  plotted  it  turned  out  that  the  long 
lead  order  point  came  before  the  preliminary  Design  Review  (PDR)  on  the 
item  in  question,  an  extremely  risky  way  to  do  business.. 

Schedule  of  Related  Programs 

If  your  program  is  tied  to  another  development  effort,  (most  are 
these  days),  be  sure  to  have  the  main  elements  of  that  effort  plotted  on 
your  master  schedule.  This  will  require  a reliable  and  accurate  information 
flow  from  the  organization  developing  the  related  system.  Usually  this 
can  be  specified  in  a Memorandum  of  Agreement  (MOA)  between  the  two  organi- 
zations. When  the  information  does  arrive  be  sure  that  it  is  validated 
by  a responsible  individual  and  properly  dated.  Once  you  receive  this 
information,  plot  it  exactly  as  received.  You  will  probably  get  Informal 
corrections  and  updates  in  between  your  formal  reports,  these  should  be 
plotted  in  pencil  or  in  some  other  tentative  manner  but  do  not  rearrange 
your  schedule  on  the  basis  of  a phone  call  unless  you  are  100%  sure  of 
your  sources. 

Decision  Point  "Gap”  Problems 

I mentioned  earlier  that  the  DSARC  process  tends  to  cause  problems 
to  programs  because  it  creates  pauses  and  gaps  as  programs  transition 
from  one  phase  to  another.  This  problem  becomes  acute  when  two  or  more 
contractors  are  on  board  in  one  phase  and  only  one  is  to  be  selected 
for  the  next  phase.  When  to  announce  the  winner!  Before  or  after  DSARC? 
Which  technical  approach  goes  into  the  DCP  if  a source  selection  is  in 
process?  How  long  should  contract  proposal  offers  be  valid  - source 


24 


selection  time  alone  or  source  selection  plus  DSARC  time?  These  are 
the  questions  that  face  the  program  planner  at  these  decision  points. 

I strongly  recommend  that  a plan  be  developed  in  detail  to  cover 
these  transition  periods.  Most  programs  I’ve  reviewed  seem  to  schedule 
DSARC  decisions  after  rhe  contract  effort  for  the  previous  stage  is 
complete.  I don’t  recommend  this.  I believe  that  to  force  contractors 
to  "stand  down"  during  DSaRC  decisions  is  extremely  wasteful  and  there 
is  no  doubt  in  ray  mind  that  DOD  pays  for  these  pauses  in  the  end.  I 
recommend  that  some  form  of  level  of  effort  work,  long  lead  fabrication, 
testing,  and  whatever  else  seems  consistent  with  program  strategy  be 
planned  during  these  periods.  These  efforts  should  be  planned  so  that 
the  contracts  expire  60  to  90  days  after  the  scheduled  DSARC  decision 
point.  If  the  DSARC  decision  is  negative  the  old  contracts  can  then  be 
allowed  to  expire  and  the  program  terminated.  If  the  DSARC  decision  is 
for  delay  prior  to  entry  into  the  next  stage  of  development,  the  contract 
can  be  modified  accordingly.  Lastly,  if  the  decision  is  positive  the 
award  of  the  new  contract  for  the  next  phase  can  be  made  and  the  old  ones 
allowed  to  expire. 

Bear  in  mind  that  this  strategy  must  be  approved  and  should  be 
reflected  in  the  Program  Management  Plan  (PMP)  and  Advanced  Procurement 
Plan  (APP).  Also  bear  in  mind  that  the  Information  required  to  write  the 
DCP,  prepare  the  DSARC  briefings  and  otherwise  convince  the  acquisition 
leadership  that  the  program  should  proceed  must  be  complete  well  in  advance 
of  the  DSARC  decision  point  even  though  the  contracts  do  not  expire  at 
that  time. 
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Planning  ProRrammlna  Budsetlng  System  (PPES) 


Earlier  I mentioned  that  the  grid  should  be  laid  out  in  both  fiscal 
and  calendar  years.  In  addition  to  this  I recommend  that  somewhere  on 
the  margin  of  the  schedule  the  major  events  of  the  PPBS  cycle  be  plotted. 
This  data  should  show  where  the  five  year  Defense  Plan  (FYDP),  the  Program 
Objective  Memorandum  (POM),  and  the  budget  submittals  are  for  each  fiscal 
year.  This  information  will  be  a great  aid  when  later  using  the  schedule 
to  work  real  world  problems.  Information  regarding  these  cycles  can  be 
obtained  from  the  comptroller  at  your  buying  division.  Other  sources  of 
data  are: 

(a)  Fiscal  and  Life  Cycles  of  the  Defense  Systems  (March  75) 
second  ed.  General  Dynamics,  Pomona  Dlv. 

(b)  DODI  7045.7  "The  Planning  Programming  and  Budgeting  System" 

Oct  29,  1969. 

(c)  HQ  USAF  Operating  Instruction  27-1,  "DOD  Programming  System", 

26  Sep  73 

Validation  and  Adjustment 

The  master  schedule  should  now  be  complete  in  its  initial  form.  If 
you  do  not  have  several  situations  that  indicate  problems  and  conflicts 
by  this  point  your  program  is  well  structured.  Usually  there  are  a number 
of  areas  that  just  don’t  mesh  and  need  to  be  corrected  after  the  first 
schedule  iteration. 

As  mentioned  earlier,  each  source  of  information  should  now  be  brought 
in  to  view  the  schedule  (one  at  a time).  These  sources  should  validate 
your  effort  or  correct  it.  Often  during  these  sessions  previous  schedule 
problems  will  be  resolved  as  the  validator  sees  how  his  or  her  part 
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of  the  program  is  out  of  phase.  Differences  of  opinion,  organizational 
differences,  and  other  problems  which  lead  to  schedule  miss-matches  can 
now  be  brought  to  the  program  manager  who  has  the  ultimate  responsibility 
to  validate  the  schedule  in  its  integrated  form.  How  the  schedule  can  be 
used  after  validation  is  the  topic  of  the  next  section. 
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SECTION  V 


USE  OF  THE  MASTER  SCHEDULE 


Master  Baseline 

The  master  schedule  for  a program  should  serve  as  a time  reference 
baseline  for  the  program.  In  order  to  do  this  it  must  be  kept  up  to  date 
with  the  approved  program  for  cost,  schedule,  and  performance.  By 
approved  program  I mean  the  official  approved  schedule  which  will  achieve 
approved  performance  levels  within  approved  cost  allocations.  There  is  a 
maintenance  task  here  akin  to  that  Inherent  in  configuration  control. 
There  will  be  many  changes  in  any  devlopment  program  and  these  changes 
grow  through  an  individual  life  cycle  of  their  own.  Program  changes, 
whatever  their  source,  start  as  proposals,  grow  into  a firm  plan,  and 
eventually  are  incorporated  into  the  program  as  approved  changes.  When 
to  plot  these  is  a question  of  judgement  and  should  reflect  the  policy  of 
the  program  manager.  Each  change  should  be  plotted  as  a proposed  or 
tentative  change  until  the  change  is  approved.  A permanent  record  of 
each  change  should  be  maintained  and  illustrated  where  required.  If  the 
program  has  slipped,  the  slip  should  be  shown  until  it  no  longer  serves  a 
purpose  to  do  so. 

Schedule  Discipline 

The  degree  of  schedule  discipline  imposed  within  the  pro;;,ram  office 
can  be  a major  factor  in  the  use  of  the  master  schedule.  Whenever  copies 
of  the  master  schedule  are  made  they  should  be  dated  and  should  be 
authenticated  by  the  signature  of  the  program  director  or  his  appointed 
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schedule  manager.  Undated  and  unauthenticated  schedules  should  not 
be  released  outside  the  program  office.  These  are  simple  rules  but  many 
programs  do  not  follow  them  and  consequently  suffer  from  the  unauthorized 
release  of  schedule  information  that  is  not  integrated  into  the  master 
schedule  and  not  approved  by  the  program  manager. 

Program  Reviews 

The  master  schedule  can  serve  as  the  framework  for  periodic  program 
reviews  within  the  program  office.  If  constructed  properly,  the  schedule 
will  illustrate  the  top  few  levels  of  the  Program  Work  Breakdown  Structure 
(WBS)  and  therefore  will  likely  be  compatible  with  the  programs  Cost/ 
Schedule  Control  System  reporting.  Program  reviews  can  serve  as  an 
excellent  forum  for  the  resolution  of  schedule  conflicts  and  the  genesis 
for  controlled  change  to  the  schedule  from  within  the  program  office.  Most 
of  the  important  leaders  on  the  program  office  team  are  present  at  these 
reviews  and  therefore  proposed  schedule  changes  or  slips  can  receive  wide 
dissemination  within  the  organization  in  this  forum. 

"What  If"  Exercises 

The  master  schedule  can  serve  as  the  framework  for  the  "what  if" 
exercises  that  are  imposed  on  programs  from  outside  the  program  office. 
Schedule  changes  can  be  plotted  manually  using  overlays  to  the  master. 

The  use  of  the  same  grid  coordinates  in  an  overlay  fashion  allows  the 
program  office  to  see  clearly  and  graphically  the  effect  of  compressions 
or  extensions  of  the  various  sub-milestones  on  the  program.  Without  the 
master  to  utilize  as  a baseline  these  exercises  tend  to  require  much 
longer  to  accomplish  and  often  overlook  important  variances  from  the 
established  program  baseline  schedule  or  plan. 


Program  Briefings 


The  master  schedule  can  also  serve  as  the  baseline  for  program 
reviews  at  higher  headquarters  and  other  places  external  to  the  program 
office.  Most  programs  have  certain  key  milestones  which  are  taken  from 
the  master  schedule  and  presented  in  summary  form  on  view  graphs  or 
slides.  If  these  do  not  show  the  detail  required  to  make  a point  the 
time  span  of  the  slide  can  be  reduced  down  to  the  point  where  the  details 
are  visable.  In  last  resort  the  master  schedule  can  be  transported  with 
the  team  accomplishing  the  briefing  but  I do  not  recommend  this.  The 
handling  is  usually  very  hard  on  the  paper  and  almost  always  results  in  a 
redrawing  requirement  when  you  return  to  the  program  office.  (Remember, 
this  schedule  is  usually  on  the  order  of  7'  to  10’  X 10'  to  15'  in  size) 
With  these  uses  in  mind  let  me  now  turn  to  the  subject  of  mechaniza- 
tion of  the  scheduling  effort. 
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SECTION  IV 


PROS  and  CONs  of  Mechanization 


It  has  been  my  observation  that  many  programs  have  a tendency  to 
look  to  mechanization  or  automation  of  their  scheduling  effort  as  a 
"cure  all"  for  scheduling  problems  and  responsibilities.  The  purpose 
of  this  section  is  to  sort  out,  for  the  program  considering  mechaniza- 
tion, some  of  the  pros  and  cons  I have  seen  in  the  field  as  programs 
attempted  to  automate  or  mechanize  their  scheduling  process. 

Some  PROS 

One  advantage  of  an  automated  system  is  that  it  is  easy  to  update. 
Changes  are  usually  input  to  the  system  via  punched  cards,  remote 
terminals  or  the  like.  Once  the  new  data  is  in,  the  computer  redraws 
the  schedule  based  on  the  new  Inputs. 

Another  advantage  may  be  the  speed  with  which  the  computer  can 
accomplish  the  update  required.  I say,  may,  because  this  is  only  an 
advantage  if  the  program  needs  to  update  the  schedule  rapidly  for  some 
reason.  If  the  need  is  there,  most  computer  systems  can  reaccomplish 
the  schedule  in  a matter  of  minutes. 

A third  advantage  is  that  most  computer  systems  on  the  market  today 
which  have  been  adapted  to  the  process  of  scheduling  offer  the  capability 
of  gameing  or  accomplishing  "what  if"  exercises.  Many  SPOs  find  this 
capability  extremely  attractive  because  of  the  many  requests  they 
receive  for  estimates  of  what  will  happen  if  "this"  or  "that"  action 
takes  place.  These  exercises  typically  occur  during  budget  exercises 
and  have  to  be  accomplished  with  very  short  deadlines. 
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Still  another  advantage  may  be  the  mystique  of  the  computer.  I 
say  maybe  because  this  "mystique"  is  losing  its  effect  as  more  and  more 
people  become  familiar  with  computers.  But  still  there  is  a certain  aura 
about  being  able  to  say,  "this  schedule  was  derived  by  the  computer". 

Some  CONs 

The  first  is  likely  to  be  the  cost  of  the  system  to  be  utilized. 

My  caution  here  is  that  a complete  cost  analysis  be  performed.  1 have 
seen  programs  wltn  automated  schedules  that  could  not  be  cost  effective 
due  to  the  size  of  the  system  in  relation  to  the  program  office  in  question. 
How  these  systems  were  justified  I do  not  know.  I do  know  that  many  organi- 
zations simply  give  up  on  the  idea  o^  a manual  system  because  it  seems  old 
fashioned  and  unglaroorous.  It's  not  a real  cost  analysis  if  you  go  in  with 
the  idea  that  the  job  can't  be  done  manuaily.  Lastly,  be  sure  to  get 
competition  on  the  system  design  and  let  the  ADP  equipment  and  programs 
be  adapted  to  your  program  - don't  adapt  your  program  to  a given  ADP  system. 
There  are  a number  of  computer  systems  available  today  which  can  accomplish 
real-time  scheduling  and  the  market  is  highly  competititve . Use  this  to 
your  advantage.  I have  considered  the  inclusi'^n  of  a list  of  corporations 
who  market  systems  of  the  type  required  but  decided  against  it  because  I 
do  not  want  to  appear  to  favor  any  commercial  firm.  Information  regarding 
these  companies  and  the  program  offices  that  are  using  their  systems  can 
be  obtained  from  the  Program  Management  Assistance  Group  (PMAG)  at  HQ  AFSC, 
Andrews  AFB,  MD. 
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Another  con  is  the  conraunication  barrier  presented  by  the  computer » 
It  is  difficult  enough  to  get  the  wide  variety  of  people  in  a SPO  to 
accept  a common  schedule  symbology.  Getting  them  to  utilize  and  depend 
on  Computer  Symbols  which  are  new  and  strange  is  sometimes  almost 
impossible.  I know  of  one  program  where  the  schedule  is  computerized 
yet  no  one  outside  the  program  control  office  uses  the  computer  versions 
they  all  maintain  schedules  in  formats  they  like.  This  same  problem 
extends  to  people  outside  the  program  office.  I have.,  myself,  at  times, 
tried  to  work  with  a computer  schedule,  and  simply  given  up  because  I 
couldn't  follow  the  symbology.  Lastly,  the  kinds  of  schedules  required 
for  program  reviews  and  other  management  meetings  at  higher  levels  of 
authority  are  quite  different  from  the  computertized  schedules  I've  seen 
Here  again,  I find  the  need  for  dual  symbology. 

In  summary,  look  very  closely  at  your  requirement  before  you  decide 
to  mechanize.  I can't  stress  enough  to  the  program  just  getting  started 
" start  manual  — start  simple  — and  grow  from  there,  i_f  you  need  to. 
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SECTION  VII 


SUMMARY 


I was  tempted  to  c.all  this  section  "Summary  and  Conclusions"  but 
I have  dropped  the  "conclusions"  from  the  title.  I have  done  this 
because  this  paper  is  not  Intended  to  bring  the  reader  to  some  decision 
or  "conclusion".  It  is  meant  to  be  a practical  guide  for  the  development 
of  a master  integrated  schedule  for  a systems  acquisition  effort.  Having 
written  other,  much  more  rigorous  academic  papers,  I am  tempted  to  look 
back  on  this  one  as  simplistic.  That  is,  unfortunately,  in  my  opinion, 
a sign  of  the  times.  We  have,  again  in  my  opinion,  somehow  gotten  our- 
selves into  the  position  where  we  are  losing  our  (the  Air  Force  Systems 
Acquisition  Community)  ability  to  perform  the  basics,  in  this  case, 
scheduling. 

This  paper  started  with  the  statement  that  1 believe  the  scheduling 
area  of  the  three  primary  DOD  development  parameters,  (cost,  schedule, 
performance)  has  been  de-emphasized.  This  was  followed  by  the  presentation 
of  several  "horror  stories"  which  I have  personally  observed  occur  due  to 
the  lack  of  a master  integrated  schedule  and  a definition  of  what  I 
believe  such  a schedule  consists  of.  Next  came  a presentation  of  problems 
that  I have  observed  occur  in  the  field  that  prohibited  programs  from 
developing  an  effective  scheduling  capability.  The  next  section  was  a 
"cookbook"  section  on  how  to  actually  develop  and  lay  out  a master 
integrated  schedule.  This,  in  turn,  was  followed  by  sections  on  how  to 
use  the  schedule  once  developed  and  some  pros  and  cons  of  mechanizing 


the  schedule 


Looking  back,  I would  like  to  leave  the  Program  Manager  with 
the  following  messages: 

1.  If  you  dont'  have  an  Integrated  schedule  that  you  control 
and  developed  within  the  program  office,  you're  headed  for  trouble. 

2.  Don't  over  estimate  the  job  — a couple  of  smart  pe'^ /le  can 
do  amazing  things  given  a week  to  10  days. 

3.  Don't  try  to  get  too  fancy  too  fast.  Keep  it  simple  uitil 
you  know  your  people  have  mastered  the  program  and  the  basics  of  the 
process. 

4.  Use  the  schedule  as  a core  management  tool  and  make  it 
compatible  with  your  WBS  and  contract  structure. 

5.  Install  discipline  in  your  people.  Do  not  allow  program 
schedule  changes  to  get  out  of  the  program  office  until  you've  approved 
them.  Make  sure  everyone  has  the  same  schedule. 

6.  Plan  for  the  unknown.  Do  not  approach  complex  events  like 
source  seleccions  or  DSARC  gates  with  a vlewgraph  level  plan.  How  would 
you  feel  if  your  contractor  did  it  that  way? 

7.  Do  not  accept  no  for  an  answer  when  you  ask  to  have  such  a 
schedule  completed.  The  week  I wrote  this  I had  the  opportunity  to  chat 
with  the  Chief  of  Program  Control  on  a major  Joint  Service  Program.  He 
told  me  that  he  had  a person  working  for  six  months  to  get  a schedule  for 
his  program  and  never  could  get  it  done.  Don't  you  believe  it.  It  can 
be  done,  and  if  it's  not,  sooner  or  later,  the  price  will  be  paid. 
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